【レポート】IoT Well Architected #AWSSummit

AWS Summit Osaka 2019 のセッション「IoT Well Architected」のレポートです。

AWS Summit Osaka 2019

#AWS

岩田智哉

2019.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

サーバーレス開発部@大阪の岩田です 2019年06月27日に開催された AWS Summit Osaka 2019 のセッション「IoT Well Architected」をレポートします。

スピーカー(敬称略)

アマゾン ウェブ サービス ジャパン株式会社
技術統括本部
ソリューションアーキテクト
辻 義一

セッション概要

Well Architected FrameworkのIoT版にあたるIoT Lensを中心に、IoTのシステムを設計される際に参考にして頂けるベストプラクティスをご紹介します。フレームワークでは、5つの柱(運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化)に基づいて、アーキテクチャを評価します。

レポート

AWS Well-Architectedについて

AWSクラウドのアプリ設計におけるベストプラクティス 5つの柱
- 「運用の優秀性」
- 「セキュリティ」
- 「可用性」
- 「パフォーマンス効率」
- 「コスト最適化」

AWS Well-Architectedは一般的なベストプラクティス
Well-Architected レンズは特定のユースケース向け
今日のセッションはIoTのレンズについて

設計指針

収集と後続の処理をキュー、バッファ、メッセージョングサービスなどを利用して疎結合にする

キューイングを使って収集と加工処理を疎結合にする
モノリシックに1つのシステムにするのではなく、サブシステムとして分離する
収集と加工の部分を分離して疎結合にすることで、個別に開発、メンテできる
IoT固有の特徴として、メッセージが小さいという特徴がある
一件づつ処理すると負荷が高いので、まとめて処理してまとめ格納する
AWS IoTやKinesisを使う

オフライン時の動作を設計に組み込む

デバイスの最新状態を見せるようなアプリの例
- 最新ステータスを都度デバイスに問い合わせるのではなく、デバイスから定期収集したデータを使う
デバイスからは最小化したデータをクラウドに送り、アプリケーション側で表示等をしやすいように加工しておく
- デバイスの性能もNWも限られている
- 料金も高くなる
- 圧縮、バイナリ、差分・増分のみの送信等
- UI向けには後処理で加工する
デバイスのステータスを定期的に送信する
- CPU使用率等のメトリクスを定期的に送信する
- 手元にないデバイスの情報を把握できる

運用の優秀性

設計上のポイント

デバイスのプロビジョニング
- 秘密鍵、証明書の組み込み
- デバイスとユーザーの紐付け
- これらの作業をいつ、どこで、誰がやるか？
デバイスの起動プロセス
- イメージの署名検証
- エンドポイントや設定の自動更新
- ファームウェアの更新
- 国を検出してエンドポイントを自動で設定等
OTAを実装する
- ネットワーク経由でのファームウェアアップデート
- アップデートのプロセスをどう実現するか？
- 不具合のあるファームウェアを全デバイスに配布し得るような設計にしない
物理デバイスの自己診断機能を実装する
- デバイスから自分の状況をレポートする

ホワイトペーパーのQ&A紹介

何に基づいて運用の優先事項を決めるか？
- ビジネス成果
- ビジネス成果に紐づく運用メトリクスが何かを考えて、取り入れる
- 例えばレスポンスタイム、Amazon Echoなら正しい会話ができるか？など
どのようにデバイスへの影響を最小限に抑えながら、IoTシステムを発展させるか？
- OTAを実装する
- 古いデバイスに対しても新しい機能に対応させる
- 全台同時実行ではなく、徐々に実行する
- 成功率を監視して継続 or 中止を自動判断させる
- 一定以上の期間は下位互換性を実現する

セキュリティ

ビジネス価値を継続的に提供しながら資産を守る

設計上のポイント

デバイスの認証情報を安全に保存する

秘密鍵と証明書がオススメ
- セキュアエレメントと呼ばれる専用のチップに秘密鍵を置く
- フラッシュメモリに置くと、配線をいじって盗まれるようなケースもあり得る
- 製品に合わせて検討を
デバイスの認証情報ライフサイクルを実装する
- 出荷したデバイスの証明書の有効期限が切れる場合、更新の必要がある
- 秘密鍵と証明書が盗まれた場合の無効化などを考慮する
デバイスには最小限の権限を付与
- デバイスから上がってきた要求を鵜呑みにしない
- セキュリティリスクを考慮
- トピックの設計で吸収する

ホワイトペーパーのQ&A紹介

ユーザーがIoTアプリケーションへアクセスする際の認証認可をどのように行うか？
- パスワード、ソーシャルIDP(FaceBook等)、AWSならCognito
- 適切なデバイスとの紐付け(1-1,1-N,N-N)
- デバイスとユーザーも含めた権限管理
- デバイスが他のサービスにアクセスする際の認証・認可
- API GWやS3にアクセスさせたい場合、Iot Core経由なら問題なしだが、IoT Coreを経由しない場合は、デバイスの認証・認可が課題
- 安全な認証方式が確立できているシステムから認証トークンを発行する
  - IosTCoreからトークンを発行
  - AWS IoTではIAMロールのトークンを発行できる
  - トークンに含まれるデバイス情報で他のマネージメントサービスへの認可も可能
デバイスのログ、メトリクス、設定をどのように監視しているか？
- クラウドに送り、分析・監視する
- AWS IoT Device Defenderでデバイスのメトリクスを継続的に分析して異常を検知できる
デバイスに影響するインシデントにどのように準備しているか？
- デバイスは属性、バージョンなどで分ける。調査やリモートコマンド操作、OTAができるように運用する
- 詳細なログ、メトリクスを集められるようにしておく
- デバイスを無効化できるようにしておく
- 手順や自動化の準備を

信頼性

設計上のポイント

本番規模のデバイス動作をシミュレートしてテストする
- 実際のデバイスを1万台用意するのは非現実的　EC2等で仮想的なデバイスを用意してテストする
- AWSのサービス制限や負荷情報、ログなどに注意しながら徐々に負荷を上げていく
- MAXの10%から初めて徐々に負荷を上げる等
メッセージ配信はストリームやキューでバッファする
- 失敗や障害などを想定した信頼性の高い設計にする
- クラウド側だけでなく、デバイス側でも再施工やロールバックを
- Design for failure

ホワイトペーパーのQ&A紹介

負荷のピークに対する制限にどのように対応しているか？
- 自動的にスケールアウト可能な構成にする
- AWSサービスの制限を確認し、計画的に緩和申請を
- Exponential BackOFF retryやキューイングを行う
- 不要なピークが発生しないようにする
- 全デバイスが毎日0:00に処理するような設計は避ける。本当に0:00にする必然性があるのか？
- 不要なピークは不要なコストを生む